1. Technical Field
The invention relates generally to processing transactions, and more specifically, to a solution for more efficiently processing and/or responding to a request for a transaction that requires multiple resources.
2. Background Art
Many transactions require that operations be performed on multiple resource managers and/or multiple resources under the same resource manager. For example, a distributed XA transaction may be requested that requires entries to be added and/or changed in multiple databases. In these transactions, it is typically desired that either all the operations occur successfully or none of the operations occur at all. In order to ensure this, the operations can be performed using the XA protocol, which supports a two phase process. In the first phase, each resource is “prepared.” Preparing a resource includes providing the operation to the resource manager, performing the operation on the resource, and obtaining and temporarily storing result(s) for the operation. The result(s) from the resource manager is then returned to a transaction manager that manages the entire transaction. When the returned results indicate that all operations were successful, each resource can be “committed” in the second phase. Committing a resource includes making the result(s) of the operation permanent in the resource. However, if the returned results indicate that one or more operations failed, then each resource can instead be “rolled back” in the second phase. Rolling back a resource includes undoing the result(s) of the operation performed when the resource was prepared in the first phase as well as any operations performed on the resource prior to the preparation.
Typically, in processing a transaction that spans multiple resources, each resource is serially prepared and serially committed or rolled back. For example, when two resources are required, the first resource is prepared, and when a successful preparation response is received, the second resource is prepared. Assuming both resources are prepared successfully, the first resource is committed followed by committing the second resource. Once both resources have been successfully committed, the transaction manager provides a response to the requester.
Serially processing resources for the transaction can be inefficient. For example, one or more resources may have a separate resource manager that is concurrently performing actions for other systems. As a result, when the transaction manager requests that the resource manager perform an operation, there may be some delay before the operation is performed and a response is received. When numerous resources are required for a transaction, these delays can accumulate into a substantial delay in responding to the transaction request.
As a result, a need exists for an improved solution for processing transactions that require multiple resources. In particular, a need exists for a method, system and program product that more efficiently process a transaction by simultaneously preparing and/or committing resources before replying to the requester.